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(54) Method and apparatus for provisioned and dynamic quality of service in a communications 
network 



(57) A method and apparatus for providing provi- 
sioned and dynamic QoS in a communications network. 
In one embodiment, provisioned QoS is provided in a 
network using NHRP by deciding to establish an SVC 
for a sender and receiver. An NHRP resolution reply 
containing QoS information is received in response to 
an NHRP resolution request. An appropriate SVC is 
then established using the QoS information. In another 



embodiment, dynamic QoS is provided in a network us- 
ing RSVP. A first RSVP multicast connection tree with a 
first QoS is established in response to an RSVP request. 
When a second RSVP request is received, a new tree 
is created if the QoS in the second RSVP request is not 
within a threshold range from the QoS of the first tree. 
If the QoS in the second RSVP request is within the 
threshold range, a new branch is added to the first tree 
and no new RSVP connection tree is required. 



FIG. 3 
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Description 

FIELD OF THE INVENTION 

[0001 ] The invention relates to the transfer of informa- 
tion in a communications network. More particularly, the 
invention relates to a method and apparatus for provi- 
sioned and dynamic quality of service (QoS) in a com- 
munications network. 

BACKGROUND OF THE INVENTION 

[0002] A communications network, such as the Inter- 
net, can transmit packets of information between inter- 
connected communications sites. Information, such as 
text, music or video, at an originating site is divided into 
a number of small information packets which are trans- 
mitted over the network using a protocol such as Internet 
Protocol (IP). Each packet can travel though a number 
of communications sites, called a "path" or "route," be- 
fore reaching the destination site. Thus, some commu- 
nications sites are called "routers* because they direct 
a packet to the next leg, or "hop," of the route towards 
the destination. When all of the packets have arrived at 
the destination, they are reassembled to create the in- 
formation, such as the text, music or video, that was 
originally transmitted. IP is called a "connection-less" 
system because, each individual packet of information 
can take a different path to reach the destination site. 
[0003] A communication that relies solely on IP can 
be unreliable due to packet loss, reordering and dupli- 
cation. The IP delivery model is often referred to as a 
"best effort" system and an additional end-to-end proto- 
col, such as Transmission Control Protocol (TCP), is re- 
quired to provide reliability. TCP achieves this through 
mechanisms such as packet retransmission, which 
adds to the overall information transfer delay. 
[0004] The best effort communications model is ade- 
quate for some network applications, such as File Trans- 
fer Protocol (FTP) and e-mail. For other network appli- 
cations, however, such as those using multimedia infor- 
mation, the delay and other problems caused by the 
best effort model can be unsatisfactory. For these appli- 
cations, a method of ensuring a certain QoS, including 
bandwidth, delay and packet loss guarantees, is re- 
quired. 

[0005] To meet this need, a dedicated-connection 
switching technology, called Asynchronous Transfer 
Mode (ATM), has been developed. ATM is a "connec- 
tion" oriented system because a specific path, called a 
Switched Virtual Circuit (SVC), is established between 
an origin and a destination. Every information packet 
flowing from that origin to that destination travels over 
the same SVC. Such an arrangement allows the system 
to establish a specific QoS for a specific flow. This can 
be done, for example, by reserving resources, such as 
bandwidth, along the path of the SVC when the SVC is 
created. 



[0006] Because of the differences between IP and 
ATM, various protocols have been developed to trans- 
mit IP traffic over an ATM network infrastructure. Two 
such protocols are the Next Hop Resolution Protocol 
5 (NHRP) and the Resource Reservation Setup Protocol 
(RSVP). 

[0007] As shown in FIG. 1 , the NHRP system is a pro- 
visioned reservation protocol used by NHRP Servers 
(NHS) 110, 120, 130, 140 and NHRP Clients (NHC) 10, 
io 20 which communicate over a network 100. The network 
100 can be comprised of a number of smaller networks, 
called Logical IP Subnetworks (LIS), that communicate 
with each other using ATM. When an NHC-A 10 wants 
to send information to an NHC-B20 using the IP address 
15 of the NHC-B 20, the information can be sent to an in- 
gress NHS 110. The ingress NHS 110 can forward the 
information to the NHC-B 20 through an NHS-Y 1 20, an 
NHS-Z 130 and an egress NHS 140. 
[0008] Obviously, this is not an optimal communica- 
te tion path between the NHC-A 10 and the NHC-B 20. If 
the NHC-A 10 could determine the ATM address of the 
NHC-B 20, information could be sent directly using a 
SVC from NHC-A 10 to NHC-B 20. NHRP allows the 
NHC-A 10 to send the IP address of NHC-B 20 to the 
25 ingress NHS 110 in an NHRP address "resolution re- 
quest." The ingress NHS 110 maintains a table contain- 
ing the IP address and ATM address of each member 
in its associated LIS. 

[0009] If, as shown in FIG. 1, the NHC-B 20 is in a 

30 different LIS, the ingress NHS 1 1 0 will not know the ATM 
address of NHC-B 20. In this case, the ingress NHS 110 
can forward the resolution request to the NHS-Y 120. 
Likewise, the NHS-Y 120 and the NHS-Z 130 can for- 
ward the request until it reaches the egress NHS 140. 

35 The egress NHS 140 can then reply with the ATM ad- 
dress of the NHC-B 20, back along the same path taken 
by the request. With this information, the NHC-A 10 can 
establish an end-to-end connection 1 50, called a "short- 
cut," to transfer IP packets to the NHC-B 20. 

40 [0010] The traditional NHRP system, however, has 
several disadvantages. Foremost is the inability to take 
advantage of the QoS capabilities of ATM when trans- 
porting IP information. There is no way, for example, that 
a sender can know the QoS preferences or limitations 

45 of a receiver using NHRP. Moreover, when a small 
number of packets are being transmitted, the time and 
traffic required to establish the shortcut 150 can be 
greater than the time and traffic saved by the shortcut 
150. Also, the traditional NHRP implementation does 

50 not take into account that there may be specific origins 
and/or destinations that will always require a shortcut 
with a specific QoS. 

[0011] Unlike NHRP, RSVP is a generic IP network 
reservation protocol that allows a specific QoS to be es- 
55 tablished for an IP data flow. When an application re- 
quests a specific QoS, RSVP is used to deliver the re- 
quest to each router along the path of the data stream 
to reserve resources along the data path. The paths 
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used to communicate with RSVP are "dynamic" in that 
they can change over time. It should be noted that RSVP 
is not necessarily directly related to the use of ATM. 
[0012] RSVP also supports the simultaneous trans- 
mission of information to multiple destinations, called 
"multicast." As shown in FIG. 2, a sender host H1 210 
can multicast information to several receiver hosts H3 
230, H4 240 and H5 250 through a network of routers 
including R1 260, R2 270, R3 280 and R4 290. With 
RSVP, the receiver hosts 230, 240, 250 are responsible 
for requesting resource reservations. Each receiver 
host can request a QoS tailored to its particular need by 
sending RSVP reservation messages "upstream" to- 
wards the sender host 210. Just as the data branches 
out downstream in the routers 260, 270, 280, 290, the 
reservation messages going upstream are "merged". A 
single reservation message need only flow upstream 
until it is merged with another reservation message. A 
single host can act as both a sender and a receiver, and 
a different QoS might be required for each role. 
[001 3] When used strictly with respect to I P, an RSVP 
multicast tree can support a different QoS for each leaf 
in the tree. However, when used to transfer information 
with respect to ATM, the typical point-to-multipoint tree 
in an ATM system can only support a single QoS. Dif- 
ferent receiver hosts on the same multicast tree, how- 
ever, might have different capabilities and therefore 
need different QoS. The traditional ATM implementa- 
tion, therefore, requires that a separate delivery tree be 
created for each requested QoS. This increases the 
amount of traffic on the network. Alternately, the QoS of 
a single tree can be continuously adjusted to the level 
of the most demanding receiver. This will result in some 
receivers getting a QoS that was not requested. Such 
an arrangement is not desirable because a network pro- 
vider may charge each receiver a different rate based 
on the requested QoS. 

[0014] In view of the foregoing, it can be appreciated 
that a substantial need exists for a method and appara- 
tus that provides provisioned QoS in a network using 
NHRP, and solving the other problems discussed above. 
Moreover, it can be appreciated that a substantial need 
exists for a method and apparatus that provides dynam- 
ic QoS in a network using RSVP and solving the other 
problems discussed above. 

SUMMARY OF THE INVENTION 

[0015] The disadvantages of the art are alleviated to 
a great extent by a method and apparatus for providing 
provisioned and dynamic QoS in a communications net- 
work. In one embodiment, provisioned QoS is provided 
in a network using NHRP by deciding to establish an 
SVC for a sender and receiver. An NHRP resolution re- 
ply containing QoS information is received in response 
to an NHRP resolution request. An appropriate SVC is 
then established using the QoS information. 
[0016] In another embodiment, dynamic QoS is pro- 
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vided in a network using RSVP. A first RSVP multicast 
connection tree with a first QoS is established in re- 
sponse to an RSVP request. When a second RSVP re- 
quest is received, a new tree is created if the QoS in the 

s second RSVP request is not within a threshold range 
from the QoS of the first tree. If the QoS in the second 
RSVP request is within the threshold range, a new 
branch is added to the first tree and no new RSVP con- 
nection tree is required. 

10 [0017] With these and other advantages and features 
of the invention that will become hereinafter apparent, 
the nature of the invention may be more clearly under- 
stood by reference to the following detailed description 
of the invention, the appended claims and to the several 

is drawings attached herein. 

BRIEF DESCRIPTION OF THE DRAWINGS 

[0018] FIG. 1 is a block diagram that shows a com- 
munications network using NHRP. 
[0019] FIG. 2 is a block diagram that shows a com- 
munications network using RSVP. 
[0020] FIG. 3 is a block diagram that shows NHRP 
being used to provide provisioned QoS according to an 
embodiment of the present invention. 
[0021] FIG. 4 is a block diagram that shows RSVP be- 
ing used to provide dynamic QoS according to another 
embodiment of the present invention. 
[0022] FIG . 5 is a flow diagram showing a process that 
can be used when providing dynamic QoS according to 
the embodiment shown in FIG. 4. 

DETAILED DESCRIPTION 

[0023] The present invention is directed to a method 
and apparatus for provisioned and dynamic QoS in a 
communications network. In particular, the following 
sections describe embodiments directed to: (1) provi- 
sioned QoS in a network using NHRP; and (2) dynamic 
QoS in a network using RSVP 

Provisioned QoS in a Network using NHRP 

[0024] Referring now in detail to the drawings wherein 
like parts are designated by like reference numerals 
throughout, FIG. 3 shows an embodiment of the present 
invention directed to provisioned QoS in a network using 
NHRP A number of NHRP Servers (NHS) 310, 320, 
330, 340 and NHRP Clients (NHC) 301 , 302 communi- 
cate over a network 300. The network 300 shown in FIG. 
3 includes three Logical IP Subnetworks (LIS) that com- 
municate with each other using ATM. As described with 
respect to FIG. 1 , when it is decided that a shortcut 350 
will be established from a sender NHC 301 to a receiver 
NHC 302, the sender NHC 301 issues an NHRP ad- 
dress "resolution request" containing the IP address of 
the receiver NHC 302. The resolution request is for- 
warded by an ingress NHS 310, an NHS-Y 320 and an 
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NHS-Z 330 until it reaches an egress NHS 340. 
[0025] The message returned to the sender NHC 301 
in response to the resolution request is called an NHRP 
"resolution reply" message. According to this embodi- 
ment of the present invention, the typical NHRP resolu- 
tion reply message can be modified to include QoS in- 
formation in addition to the ATM address of the receiver 
NHC 302. As explained in detail below, this QoS infor- 
mation can be used to create an SVC having an appro- 
priate QoS, such as a guaranteed bandwidth. 
[0026] When the egress NHS 340 receives the reso- 
lution request, it will respond with the ATM address of 
the receiver NHC 302. The traffic descriptor limits for the 
egress node can be stored in the vendor specific exten- 
sion of the reply message. A vendor extension field can 
contain a vendor ID and opaque data, and can be at- 
tached to any NHRP request or reply. The traffic descrip- 
tor limits can include the maximum values for the follow- 
ing parameters: Peak Cell Rate (PCR); Sustainable Cell 
Rate (SCR); Minimum Cell Rate (MCR); and Maximum 
Burst Size (MBS). 

[0027] The QoS parameters can be stored in commu- 
nications switches and exchanged by the ingress switch 
310 and egress switch 340. This can be done using the 
vendor extension field of the NHRP packet. According 
to this embodiment of the present invention, QoS pa- 
rameters are placed in the vendor extension field of an 
NHRP packet to be transported between the ingress 
and egress switch. 

[0028] For example, for the parameter profile associ- 
ated with each type of IP flow, the switch could support 
the options to assign UNI 4.0 parameters (i.e., PCR, 
SCR, MCR, MBS, bearer class, QoS class and HLI in- 
formation) that correspond to those for : Constant Bit 
Rate (CBR), real-time Variable Bit Rate (VBR), non-real- 
time VBR, Unspecified Bit Rate (UBR) or Available Bit 
Rate (ABR) connections. These parameters can be 
specified for the direction of the data flow away from the 
logical port on the ingress NHS 310 and towards the 
egress NHS 340. 

[0029] In addition to the parameter profiles associated 
with IP flows, an NHS could also, associate the following 
information with logical ports: the maximum PCR, max- 
imum SCR, maximum MCR and maximum MBS values 
for the data flow to and from the given logical port. A 
single set of maximum values could apply for the flows 
in either direction. 

[0030] The desired minimum traffic parameters con- 
tained in the parameter profile for a given flow should 
be constrained not to exceed the above maximum val- 
ues associated with the logical port through which the 
flow enters the network. Default maximum PCR, SCR, 
MCR and MBS values can also be associated with each 
logical port. Finally, if the NHRP request came from an 
ATM attached end station outside the network, then min- 
imum computed values, as well as other parameters re- 
quired to establish a UNI 4.0 call, are passed along to 
the originating NHRP client using the vendor extension 



field of the NHRP response. The vendor extension field 
will be ignored by NHRP clients that are not capable of 
interpreting it. 

[0031] When the sender NHC 301 receives the NHRP 
s resolution reply, it will reconcile the desired and maxi- 
mum QoS parameters and attempt to establish an ap- 
propriate SVC. Once the SVC has been established, 
flow abatement will be monitored in the switch. 
[0032] When flow abatement is detected, the SVC 
io can be removed. The sender NHC 301 can cache the 
destination address and traffic descriptor limits to expe- 
dite future shortcut establishment if the flow is resumed. 
[0033] When an NHRP reply is received, the sender 
NHC 301 can compute the minimum of: (a) the PCR 
is maintained locally for the given direction of data flow and 
(b) the maximum PCR returned by the terminating NHS 
340 for the same direction of data flow. Minimums for 
the SCR, MCR and MBS values can be similarly com- 
puted. These values, along with other desired parame- 

20 ters, can be used to set up the SVC shortcut 350. Since 
the SVC will carry traffic only in one direction, a band- 
width of zero can be specified for the reverse direction. 
[0034] This embodiment of the present invention sup- 
ports the ability to provision bandwidth and QoS guar- 
ds antees for various types of IP flows. As used herein, an 
"IP flow" refers to a set of packets matching a particular 
profile defined in terms of source and destination IP ad- 
dresses, IP protocol, source and destination port num- 
bers, and Type of Service (ToS) requirements. Wild- 

30 cards can be used for parameters to indicate "donl care" 
status. QoS traffic descriptors may include User Net- 
work Interface (UNI) 4.0 parameters specified in the di- 
rection of data flow from source to destination, that is 
from the ingress to the egress node. 

35 [0035] The IP flow profile can also include trigger cri- 
teria defining flow onset and abatement. This could be 
helpful because the time and traffic required to establish 
the shortcut 350 can be greater than the time and traffic 
saved by the shortcut 350 when a small number of pack- 

40 ets are being transmitted. Therefore, the decision to es- 
tablish the shortcut 350 might only be made when the 
number of packets observed for the IP flow over a spec- 
ified time interval exceeds a specified threshold. 
[0036] Also, there may be specific origins and/or des- 

45 tinations that will always require a shortcut having a spe- 
cific quality of service. These factors, therefore, can be 
considered when deciding to establish the shortcut 350 
having an appropriate QoS. For example, an IP switch 
could attempt to map IP flows into ATM SVCs having 

so service characteristics based on the provisioned infor- 
mation for the port from which the flow is first detected. 
[0037] The following conditions are another example 
of when an NHRP resolution request could be sent from 
a Proxy NHC residing on the ingress node: (1) an IP 

ss packet arrives on a logical port for which NHRP request 
initiation have been enabled; (2) the packet belongs to 
an IP flow with which a parameter profile has been as- 
sociated; (3) a corresponding shortcut connection does 
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not already exist; and (4) the number of SVCs on the 
port for that type of flow does not exceed the provisioned 
threshold. 

[0038] This embodiment of the present invention can 
be implemented using an NHC or a communications 
switch acting as a proxy NHC. Either of these could is- 
sue the NHRP resolution request to determine a desti- 
nation ATM address so that an appropriate SVC can be 
established for a particular IP flow profile. In addition to 
the ATM address, the client or proxy could receive re- 
lated QoS limits and/or traffic descriptor parameters 
stored in the vendor extension of the reply. The client or 
proxy could use this information to establish QoS guar- 
antees for the shortcut 350. 

[0039] An IP switch could use Simple Network Man- 
agement Protocol (SNMP) to create, delete and modify 
the mappings between IP flows and QoS parameters, 
as well as the mappings between logical ports and the 
maximum parameters: This could be achieved by ex- 
tending the SNMP Management Information Base 
{Ml B), and the information can be accessible by external 
systems, if desired. 

[0040] When such an IP switch is first brought up it 
could initialize itself and build a table of associated de- 
fault maximum PCR, SCR, MCR and MBS values with 
logical ports on the switch. These default values can be 
based on the speed of the logical port and can be pro- 
visionable via the central management interface. 
[0041] It would also be possible to allow the negotia- 
tion of bandwidth parameters using UNI 4.0 signaling 
when the full amount of bandwidth requested is not 
available on the route. This could be dependent on the 
logical port for which the QoS parameters are main- 
tained. 

Dynamic QoS in a Network Using RSVP 

[0042] Another embodiment of the present invention 
is directed to dynamic QoS in a network using RSVP. 
Referring nowto FIG. 4, a blockdiagram showing RSVP 
being used to provide dynamic QoS according to this 
embodiment, an IP flow can be established between a 
sender 410 and a first receiver 420. In particular, this 
embodiment is directed to the simultaneous transmis- 
sion of information to multiple receivers, called "multi- 
cast." As can be seen in FIG. 4, a multicast flow can 
travel through a number of routers 442, 444, 446 in the 
network, and this path 450 is commonly referred to as 
a "delivery tree." 

[0043] When the first tree 450 was created, a specific 
QoS was requested by the first receiver 420. Each rout- 
er 442, 444, 446 in the first tree 450 reserved the re- 
sources appropriate to support the requested QoS. As 
previously explained, ATM allows a single tree, such as 
the first tree 450, to support only a single QoS for a point- 
to-multipoint connection. 

[0044] A second receiver, however, can request the 
multicast information from the sender 410 with a QoS 



different from the QoS being provided by the first tree 
450. According to the present invention, if the QoS re- 
quested by the second receiver is outside a threshold 
range from the QoS being provided by the first tree 450, 

s a second delivery tree 470 is established from the send- 
er 41 0 to the second receiver 430. In this case, the first 
tree 450 will continue to provide the QoS requested by 
the first receiver 420 and the second tree 470 will pro- 
vide the QoS requested by the second receiver 430. 

10 This can be achieved by mapping the second request 
into a new ATM point-to-multipoint tree. That is, if a res- 
ervation for a different service or different parameters is 
requested by a receiver of a multicast flow already on 
an ATM point-to-multipoint connection with a single leaf, 

15 a new SVC should be established, the flow mapped into 
it, and the original SVC cleared. 

[0045] In general, individual IP flows for which reser- 
vations are requested should be mapped into individual 
ATM connections, which carry traffic only in the direction 
20 for which the reservation applies, except where the 
merging of reservations is required by the RSVP proto- 
col for multicast support. 

[0046] In contrast, if the QoS requested by the second 
receiver is within the threshold range, the second deliv- 

25 ery tree 470 is not required. Instead, a branch 460 from 
the first tree 450 will be extended to the second receiver 
430. Thus, an IP switch according to this embodiment 
of the present invention would map IP flows into ATM 
SVCs with service characteristics based on dynamic 

30 reservations, and mapping is based on RSVP requests 
from the end station. 

[0047] For example, the first reservation request from 
a receiver of a given multicast flow can be mapped into 
an ATM point-to-multipoint connection with a single leaf. 

35 Each subsequent request by another receiver of the 
same point-to-multipoint connection can be added as 
another leaf to an existing ATM point-to-multipoint tree 
for that multicast connection if (1 ) the requested service 
(controlled load or guaranteed) matches the requested 

40 service of the first leaf of that tree; and (2) the requested 
bandwidth is within a provisionable range, or threshold, 
of the requested bandwidth of the first leaf of that tree. 
[0048] Assuming that there are three QoS classes, 
such as, for example, best effort, guaranteed service 

45 and controlled load, then by grouping receivers of the 
same multicast group based on the QoS class request- 
ed there will be at most three parallel virtual circuits. This 
would conserve network bandwidth. 
[0049] In this case, if the QoS requested by the sec- 

50 ond receiver 430 is higher than the QoS being supported 
by the first tree 450, the first tree 450 could be upgraded 
to provide the higher QoS. The capability to renegotiate 
the bandwidth for a tree upward is desirable when the 
requested bandwidth is greater, but within a proviston- 

55 able range of, that of the first leaf. A second virtual circuit 
could be created, or the first virtual circuit could be torn 
down and re-established with the higher QoS request. 
[0050] If a third receiver (not shown in FIG. 4) later 
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requests a QoS, that QoS can be compared to QoS orig- 
inally used to establish the multicast delivery tree. More- 
over, if a reservation for a different service or different 
parameters is requested by a receiver of a multicast flow 
already on an ATM point-to-multipoint connection with 5 
more than one leaf, a new SVC should be established 
for that flow if the requested service does not match the 
original tree or the requested bandwidth is outside a pro- 
visionable range of that request for the first leaf that 
joined the original tree. In this way, the system can pre- io 
vent a tree's QoS from drifting too far as a result of a 
large number of small increases in QoS. 
[0051] FIG. 5 is a flow diagram showing a process that 
can be used when providing dynamic QoS according to 
the embodiment shown in FIG. 4. After beginning at step rs 
500, a first tree is established with a first QoS at step 
520 in response to a request received at step 510. When 
a second request is received at 530, it is determined if 
the QoS in the second request is within the threshold 
range from the QoS of the established tree at step 540. 20 
If the QoS in the second request is not in the threshold 
range, a new tree is established at step 550 and the 
process continues at step 590. 

[0052] If the QoS in the second request is within the 
threshold range, a branch to the existing tree is added 25 
at step 560. Moreover, if the QoS in the second request 
is greater . than the QoS of the existing tree at step 570, 
the QoS of the existing tree is upgraded at step 580 be- 
fore the process continues at step 590. 
[0053] It is expected that the support of QoS through 30 
either NHRP or RSVP will not reduce the capacities for 
routing, packet forwarding and ATM SVC setups more 
than 5% from the corresponding capacities with QoS 
disabled. In general, a switch that has the QoS features 
enabled is expected to perform on par with a switch that 35 
is doing just route filtering. 

[0054] Although various embodiments are specifically 
illustrated and described herein, it will be appreciated 
that modifications and variations of the present inven- 
tion are covered by the above teachings and within the 40 
purview of the appended claims without departing from 
the spirit and intended scope of the invention. For ex- 
ample, although PCR, SCR, MCR and MBS values were 
used to illustrate one embodiment of the invention, it can 
be appreciated that any QoS parameters could be used *s 
instead and still fall within the scope of the invention. 

Claims 

50 

1 . A method of providing provisioned quality of service 
in a communications network including a sender 
communications site and a receiver communica- 
tions site, comprising the steps of: 

55 

issuing a resolution request in accordance with 
an address resolution protocol, including the In- 
ternet protocol address of the receiver commu- 



nications site; 

receiving a resolution reply in accordance with 
the address resolution protocol, including the 
asynchronous transfer mode address of the re- 
ceiver communications site and quality of serv- 
ice information; and 

establishing a switched virtual circuit with a 
quality of service based on the quality of service 
information contained in the resolution reply. 

2. The method of claim 1 , wherein the quality of serv- 
ice information is based on the quality of service de- 
sired by the receiver communications site. 

3. The method of claim t , wherein the quality of serv- 
ice information is based on the capabilities of the 
receiver communications site. 

4. The method of claim 1 , wherein the address reso- 
lution protocol is Next Hop Resolution Protocol 
(NHRP), the resolution request is an NHRP resolu- 
tion request and the resolution reply is an NHRP 
resolution reply. 

5. The method of claim 2 wherein the quality of service 
information is contained in a vendor specific exten- 
sion of the NHRP resolution reply. 

6. The method of claim 1 , wherein said steps of issuing 
and receiving are performed at an NHRP client. 

7: The method of claim 1 , wherein steps of issuing and 
receiving are performed at a communications 
switch acting as a proxy NHRP client. 

8. The method of claim 1 , wherein the quality of serv- 
ice information includes bandwidth information. 

9. The method of claim 1 , wherein the quality of serv- 
ice information can include peak cell rate informa- 
tion, sustainable cell rate information, minimum cell 
rate information and maximum burst size informa- 
tion. 

10; The method of claim 1, further comprising the step 
of deciding to establish the switched virtual circuit 
based on the number of information packets trans- 
mitted from the sender communications site to the 
receiver communications site and a threshold val- 
ue. 

11 . The method of claim 1 , further comprising the step 
of deciding to establish the switched virtual circuit 
based on the identity of the sender communications 
site. 

12. The method of claim 1 , further comprising the step 
of deciding to establish the switched virtual circuit 
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based on the identity of the receiver communica- 
tions site. 

13. The method of claim 1 , further comprising the step 
of deciding to establish the switched virtual circuit 
based on the identity of the sender communications 
site and the receiver communications site. 

14. The method of claim 1 , further comprising the step 
of deciding to establish the switched virtual circuit 
based on traffic in the communications network. 

15. An apparatus to provide provisioned quality of serv- 
ice in a communications network, comprising: 

means for issuing a Next Hop Resolution Pro- 
tocol (NHRP) resolution request including the 
Internet protocol address of a receiver commu- 
nications site; 

means for receiving an NHRP resolution reply 
including the asynchronous transfer mode ad- 
dress of the receiver communications site and 
quality of service information; and 
means for establishing a switched virtual circuit 
with a quality of service based on the quality of 
service information contained in the NHRP res- 
olution reply. 

16. The apparatus of claim 15 wherein the quality of 
service information is contained in a vendor specific 
extension of the NHRP resolution reply. 

17. The apparatus of claim 1 5, wherein said means for 
issuing and receiving are located at an NHRP client. 

18. The apparatus of claim 1 5, wherein means for issu- 
ing and receiving are located at a communications 
switch acting as a proxy NHRP client. 

19. The apparatus of claim 15, wherein the quality of 
service information includes bandwidth information. 

20. The apparatus of claim 1 5, wherein the quality of 
service information can include peak cell rate infor- 
mation, sustainable cell rate information, minimum 
cell rate information and maximum burst size infor- 
mation. 

21. The apparatus of claim 15, further comprising 
means for deciding to establish the switched virtual 
circuit based on at least one of the identity of the 
sender communications site and the receiver com- 
munications site. 

22. The apparatus of claim 13, further comprising 
means for deciding to establish the switched virtual 
circuit based on traffic in the communications net- 
work. 



23. A method of providing dynamic quality of service in 
a communications network including a sender com- 
munications site, a first receiver communications 
site and a second receiver communications site, 

5 comprising the steps of: 

receiving a first resource Reservation Protocol 
(RS VP) request for a connection from the send- 
er communications site to the first receiver 
io communications site, the first RSVP request in- 

cluding first quality of service information; 
establishing a first RSVP connection tree from 
the sender communications site to the first re- 
ceiver communications site, the first RSVP con- 
's nection tree being a point to multipoint tree with 
a first quality of service based on the first quality 
of service information; 

receiving a second RSVP request for a connec- 
tion from the sender communications site to the 
second receiver communications site, the sec- 
ond RSVP request including second quality of 
service information; 

establishing a second RSVP connection tree 
from the sender communications site to the 
second receiver communications site if the sec- 
ond quality of service information is not within 
a threshold range from the first quality of serv- 
ice information, the second RSVP connection 
tree being a point-to-multipoint tree with a sec- 
ond quality of service based on the second 
quality of service information; and 
adding a branch from the first RSVP connection 
tree to the second receiver communications 
site if the second quality of service information 
is within the threshold range from the first qual- 
ity of service information. 

24. The method of claim 23, wherein said step of adding 
a branch from the first RSVP connection tree further 

40 comprises the step of: 

increasing the quality of service of the first 
RSVP connection tree if the second quality of 
service is higher than the first quality of service. 

45 

25. The method of claim 24, further comprising the step 
of: 

receiving a third RSVP request for a connection 
so from the sender communications site to a third 

receiver communications site, the third RSVP 
request including third quality of service infor- 
mation; 

establishing a new RSVP connection tree from 
ss the sender communications site to the third re- 

ceiver communications site if the third quality 
of service information is not within the threshold 
range from the first or second quality of service 
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information, the new RSVP connection tree be- 
ing a point-to-multipoint tree with a third quality 
of service based on the third quality of service 
information; 

adding a new branch from the first RSVP con- 
nection tree to the third receiver communica- 
tions site if the third quality of service informa- 
tion is within the threshold range from the first 
quality of service information; and 
adding a new branch from the second RSVP 
connection tree to the third receiver communi- 
cations site if the third quality of service infor- 
mation is within the threshold range from the 
second quality of service information. 

26. An apparatus to provide dynamic quality of service 
in a communications network, comprising: 

means for receiving a first resource Reserva- 
tion Protocol (RSVP) request for a connection 
from a sender communications site to a first re- 
ceiver communications site, the first RSVP re- 
quest including first quality of service informa- 
tion; 

means for establishing a first RSVP connection 
tree from a sender communications site to the 
first receiver communications site, the first 
RSVP connection tree being a point-to- 
multipoint tree with a first quality of service 
based on the first quality of service information; 
means for receiving a second RSVP request for 
a connection from the sender communications 
site to a second receiver communications site, 
the second RSVP request including second 
quality of service information; 
means for establishing a second RSVP con- 
nection tree from the sender communications 
site to the second receiver communications site 
if the second quality of service information is 
not within a threshold range from the first qual- 
ity of service information, second RSVP con- 
nection tree being a point-to-multipoint tree 
with a second quality of service based on the 
second quality of service information; and 
means for adding a branch from the first RSVP 
connection tree to the second receiver commu- 
nications site if the second quality of service in- 
formation is within the threshold range from the 
first quality of service information. 

27. The apparatus of claim 26, wherein said means for 
adding a branch from the first RSVP connection tree 
further comprises: 

means for increasing the quality of service of 
the first RSVP connection tree if the second 
quality of service is higher than the first quality 
of service. 



28. The apparatus of claim 26, further comprising: 

means for receiving a third RSVP request for a 
connection from the sender communications 
5 site to a third receiver communications site, the 

third RSVP request including third quality of 
service information; 

means for establishing a new RSVP connection 
tree from the sender communications site to the 
10 third receiver communications site if the third 

quality of service information is not within the 
threshold range from the first quality of service 
information, the new RSVP connection tree be- 
ing a point-to-multipoint tree with a third quality 
is of service based on the third quality of service 

information; 

means for adding a new branch from the first 
RSVP connection tree to the third receiver com- 
munications site if the third quality of service in- 
20 formation is within the threshold range from the 

first quality of service information; and 
means for adding a new branch from the sec- 
ond RSVP connection tree to the third receiver 
communications site if the third quality of serv- 
es ice information is within the threshold range 
from the second quality of service information. 

29. A method of providing dynamic quality of service in 
a communications network including a sender com- 

30 munications site, a first receiver communications 
site and a second receiver communications site, 
comprising the steps of: 

receiving a first resource Reservation Protocol 
35 (RSVP) request for a connection from the send- 

er communications site to the first receiver 
communications site, the first RSVP request in- 
cluding first quality of service information; 
establishing a first RSVP connection tree from 
40 the sender communications site to the first re- 

ceiver communications site, the first RSVP con- 
nection tree being a point-to-multipoint tree 
with a first quality of service based on the first 
quality of service information; 
45 receiving a second RSVP request for a connec- 

tion from the sender communications site to the 
second receiver communications site, the sec- 
ond RSVP request including second quality of 
service information; 
50 establishing either a second RSVP connection 

tree from the sender communications site to the 
second receiver communications site or a 
branch from the first RSVP connection tree to 
the second receiver communications site 
55 based on the first quality of service information 

and the second quality of service information. 
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